In the computer software marketing and distribution industry, it is advantageous to make computer software available for use that reflects the language and culture of the intended users. A locale file is a computer resource file typically made available by a developer of a software application to assist in accomplishing this. A locale file may include a combination of specifications required to configure a software application program for a particular geographic and cultural market. These specifications typically include a language specification intended to be used to determine and control linguistic manipulation of character strings within the application program. In addition specifications for countries, regions and territories (collectively referred to herein as “country”) define cultural conventions that may vary with languages, cultures or across countries. An example of a cultural convention is a date format identifying in which order the numerals representing day, month and year appear. Other configuration preferences, such as those used to specify mail settings or favorite icons are known in the art, but are typically not included in locale files but may be included in other forms of personalization support.
Locale files are usually processed into a form which can be readily used by an application program. Compilation of a source form of a locale file is one typical means of producing an object which can be accessed by an application program needing the information provided by the locale file.
Ensuring accurate computer application program processing of information according to local cultural and geographical preferences relies on correct specifications being provided in a locale file for a given combination of language and country. In order to ensure the accuracy of specifications which are referenced by application programs, it is highly desirable to have verified localization specifications incorporated in a locale file.
Current practice in the Java programming environment includes an arrangement of segments of a predetermined syntax of stream oriented locale files containing localization specifications, for use by application programs. The practice also relies on skilled programmers to codify those specifications into a system unique definition (Java in this case) representing the requirements. In some cases agreement among programmers has caused certain values to be used in these locale files in the absence of values actually representing legitimate country requirements for programmer convenience.
Difficulties may further occur when communicating the specifications coded in a system specific form, such as Java coding, to users who have been requested to verify values, as the users may have become confused by the system format itself. The expectation that verifiers would understand the system format was not necessarily well founded as many could not understand the codified version. Additionally, these users were expected to have and use the programming environment of the system specific form to perform the actual resource specification verification.
Inaccuracies related to a locale object (“compiled or executable” form of a locale file as used by an application program) and its associated locale file may be indicated when the formatted output of the application program using that particular locale object is found to be incorrect. The locale file then needs to be corrected with appropriate changes, verified again and a new locale object built.
Verifying users may perform a visual inspection of the output of an application program that used a locale object or the program output may also be compared programmatically with previously stored reference values. It may be appreciated that either of these iterative processes can require a significant amount of time and effort to obtain desired results.
The current practice of updating the locale file and re-testing may also be error prone. Changes to the locale file may often introduce new errors, not related to language or culture specifications themselves, as the changes may have been made by the verifiers (unskilled programmers). Changes may have been suggested in error due to the confusion of verifiers during interpretation of the locale file as stated earlier. The specifications, as used in computer processing, may have been misunderstood by those verifiers not skilled in the programming art, but expert in the usage of the values themselves. The specifications may also have been created with values inserted where none were required, such as abbreviated day names where local custom does not use such short forms, by programmers not aware of the actual values. Perhaps a desire to have consistent locale files by including values where none were required may have overshadowed the need for correct resource information. In such cases form may have outweighed function.
The verification process may require the use of a different programming environment than the one in which the locale resource was intended to be used. For example, performing the verification on a workstation platform without Java support, for a locale file intended to be used on a mainframe with such support. In such cases, the locale object and related programming interfaces of the mainframe platform cannot be used directly during the verification process on the workstation platform.
It is therefore desirable to have a capability for verifying the values used in the specifications contained in locale file, in an easier more efficient manner.